REMARKS 

Reconsideration and removal of the grounds for rejection are 
respectfully requested. Claims 1-15 and 17-26, 30-32, 47 and 48 were in the 
application, claims 1-15 and 17 were withdrawn, claims 18 and 48 have been 
amended. 

Claims 18 and 48 have been amended to clarify the applicants' 
invention by including the features of applicants' invention which were 
discussed in the prior response to the office action but which were not 
included with specificity in the claims. That is, the static data and the 
dynamic data are added in dependence on the identity of the sender and of 
the party being invoiced, and further, the validation step ensures that the 
received invoices contain the data necessary for the party being invoiced to 
process the invoice. No new matter is involved in this amendment. 

Claims 18-26, 30-32 and 48 continue to be rejected as being obvious 
over U.S. Patent no. 5,708,828 to Coleman in view of either Official Notice or 
U.S. patent 5,557,780 to Edwards et al.. 

The Examiner relied on the reasons stated previously, and to an 
extent, the applicant similarly relies on the arguments stated previously, 
which are incorporated herein by reference. 

Specifically, the Examiner described the example of a customer 
providing some form of ID and perhaps a phone number. According to the 
Examiner, the teller would write the information on the check, verify it and 
then place it in a drawer for processing. According to the Examiner the static 
data would be the driver's license number and the dynamic data would be the 
phone number. However, this does not correspond to the static and dynamic 
data specified in amended claim 18. In particular, the phone number would 
not constitute "dynamic" data because it does not change. In the present 
invention, the dynamic data changes dynamically from invoice to invoice, as 
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clarified in dependent claim 20. In contrast, a phone number is static and so 
does not change from transaction to transaction. Moreover, the flow of data 
necessary to achieve the result of the present invention would be more akin 
to the teller taking the check, blanking out some information, 
changing/adding some other information, and in the process, create an 
intermediate check, then passing on the new check to a third party. This a 
teller could not do. 

Claims 18 and 48 specify also the validation of data corresponding to 
the received invoices when processed into the standard intermediate form 
before transmission to the party being invoiced to ensure that the party being 
invoiced receives the data necessary for processing the invoice. There is no 
corresponding step in the Examiner's Official Notice. Again, the teller cannot 
create a new check, the teller can only attempt to validate the identity of the 
person cashing the check, and then give them cash. The teller cannot create 
a new check or validate all the information on the check or add static or 
dynamic data in the creation of a new check, and so the teller activities do 
not lead one to the applicants invention. 

With regard to cited US 5,557,780 (Edwards et al), the Examiner 
alleges that Edwards discloses that it is known to add static and dynamic 
data and to verify the data. However, despite such generalizations, it is clear 
that the particular claim limitations found in claim 18 and 48 are not met in 
Edwards. 

As to specific limitations, claim 18 specifies that the input processor 
device is configured to: 

add static data to the data corresponding to the received invoices 
when processed into said standard intermediate form, the static data added 
in dependence on the identity of the sender and the party being invoiced ; 
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add dynamic data to the data corresponding to the received invoices 
when processed into the standard intermediate form , the dynamic data 
added in dependence on the identity of the sender and of the party being 
invoiced ; and, 

validate the data corresponding to the received invoices when 
processed into the standard intermediate form before transmission by said 
transmitter to the party being invoiced to ensure that the party being invoiced 
receives the data necessary for processing the invoice . 

In the present invention, the static data is used to fill in gaps in the 
invoice data that may not be present in the information received from the 
issuer of the invoice. Thus, the invoice data received at the input may not 
necessarily include static data such as the name, address and tax 
registration information that would traditionally be pre-printed on the 
invoicer's own conventional paper stationery and, hence not held in their own 
computer system. This gives rise to a problem when data is taken from the 
invoicer's computer and used for electronic billing, since not all the data 
required for electronic invoicing will be found in the invoicer's computer. 

Similarly, as to the dynamic data, some data components in the 
received invoice data are relationship based and the value of the data needs 
to take into account who has sent the data and who the receiver of the data 
will be. This is solved by adding appropriate dynamic data to the data 
corresponding to the received invoices and then processing into the standard 
intermediate form. The dynamic data thus varies according to the transaction 
in dependence on both the seller and the purchaser. 

Thus, the purpose of adding the static and dynamic data in the 
present invention is to ensure that when converted to the standard 
intermediate form, all of the data necessary for the receiver of the invoice is 
provided in the data that is transmitted by the invoice transmitter in the final 
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invoice to the party being invoiced. The validation of data specified in claims 
18 and 48 is an overall validation of the data in the received invoices when 
processed into their standard intermediate form before transmission to the 
party being invoiced. 

Coleman does not disclose a system containing the features 
discussed above, precisely or any other way, and thus claim 18 and the 
claims depending therefrom are not rendered obvious over Coleman. 
Edwards does not describe or suggest this approach, and so the combination 
of Coleman and Edwards would not achieve the invention claimed. 
Combining Coleman, Edwards and the Official Notice relative to bank teller 
check cashing operations does not arrive at the applicants' invention. 

Moreover, there is nothing within these patents, nor the official notice, 
which would predictably lead one skilled in the art to the results of the 
applicants' invention, and so claims 18, 48 and the claims depending 
therefrom are not obvious over these references. 

Claim 47 was rejected as being obvious over Coleman in view of U.S. 
Patent no. 4,750,1 14 (Hirtle). 

Claim 47 depends from and contains all the limitations of claim 18 
therein, and the arguments above relative to the rejection of claim 18 are 
equally applicable here. More particularly, neither Coleman nor Hirtle teach, 
suggest or would predictably lead one skilled in the art to the applicants' 
invention which specifies that the input processor device is configured to: 

add static data to the data corresponding to the received invoices 
when processed into said standard intermediate form, the static data added 
in dependence on the identity of the sender and the party being invoiced ; 

add dynamic data to the data corresponding to the received invoices 
when processed into the standard intermediate form , the dynamic data 
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added in dependence on the identity of the sender and of the party being 
invoiced ; and, 

validate the data corresponding to the received invoices when 
processed into the standard intermediate form before transmission by said 
transmitter to the party being invoiced to ensure that the party being invoiced 
receives the data necessary for processing the invoice . 

Consequently claim 47 is not rendered obvious by the cited 
combination. 

Based on the above amendments and remarks, favorable 
consideration and allowance of the application are respectfully requested. 
However should the examiner believe that direct contact with the applicant's 
attorney would advance the prosecution of the application, the examiner is 
invited to telephone the undersigned at the number given below. 



Respectfully submitted, 

/WJS/ 
William J. Sapone 
Registration No. 32,518 
Attorney for Applicant(s) 

Coleman Sudol Sapone P.C. 
714 Colorado Avenue 
Bridgeport, CT 06605 
Telephone No. (203) 366-3560 
Facsimile No. (203) 335-6779 
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